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Abstract 


Three new EVM jump instructions are introduced ( RJuMP , RJUMPI and RJuMPV ) which 
encode destinations as signed immediate values. These can be useful in the majority 
of (but not all) use cases and offer a cost reduction. 
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Motivation 


A recurring discussion topic is that EVM only has a mechanism for dynamic jumps. 
They provide a very flexible architecture with only 2 (!) instructions. This flexibility 
comes at a cost however: it makes analysis of code more complicated and it also 
(partially) resulted in the need to have the Jumppoest marker. 


In a great many cases control flow is actually static and there is no need for any 
dynamic behaviour, though not every use case can be solved by static jumps. 


There are various ways to reduce the need for dynamic jumps, some examples: 


1. With native support for functions / subroutines 
2. A “return to caller” instruction 
3. A “switch-case” table with dynamic indexing 


This change does not attempt to solve these, but instead introduces a minimal 
feature set to allow compilers to decide which is the most adequate option for a 
given use case. It is expected that compilers will use RJumMP / RJUMPI almost 
exclusively, with the exception of returning to the caller continuing to use Jump . 


This functionality does not preclude the EVM from introducing other forms of control 
flow later on. RJUMP / RJUMPI can efficiently co-exists with a higher-level declaration 
of functions, where static relative jumps should be used for intra-function control 
flow. 


The main benefit of these instruction is reduced gas cost (both at deploy and 
execution time) and better analysis properties. 


Specification 


We introduce three new instructions on the same block number EIP-3540 is activated 
on: 


1. RJuMP (Ox5c) - relative jump 
2. RIJUMPI (Ox5d) - conditional relative jump 
3. RJUMPV (Ox5e) - relative jump via jump table 


If the code is legacy bytecode, all of these instructions result in an exceptional halt. 
(Note: This means no change to behaviour) 


If the code is valid EOF1: 


1. RJUMP relative offset sets the Pc to PC_post_instruction + 
relative _offset. 

2. RJUMPI relative_offset pops a value ( condition ) from the stack, and sets 
the pc to PC_post_instruction + ((condition == @) ? © : relative offset) . 
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3. RJUMPV max_index relative_offset+ pops a value ( case ) from the stack, and 
sets the pc to PC_post_instruction + ((case > max_index) ? © : 


relative_offset[case]) . 


The immediate argument relative_offset is encoded as a 16-bit signed (two's- 
complement) big-endian value. Under Pc_post_instruction we mean the Pc position 
after the entire immediate value. 


The immediate encoding of RJumPv is more special: the unsigned 8-bit max_index 
value determines the maximum index in the jump table. The number of 
relative_offset values following is max_index+1 . This allows table sizes up to 256. 
The encoding of RjumPpv must have at least one relative_offset and thus it will take 
at minimum 4 bytes. Furthermore, the case > max_index condition falling through 
means that in many use cases, one would place the defau/t path following the 

RJUMPV instruction. An interesting feature is that RJUMPV © relative_offset is an 
inverted- RJUMPI , which can be used in many cases instead of ISZERO RJUMPI 


relative offset. 


We also extend the validation algorithm of EIP-3670 to verify that each 

RJUMP / RJUMPI / RIUMPV has a relative_offset pointing to an instruction. This means 
it cannot point to an immediate data of PUSHn / RJUMP / RIUMPI / RJUMPV . It cannot 
point outside of code bounds. It is allowed to point to a JumppesT , but is not required 
to. 


Because the destinations are validated upfront, the cost of these instructions are less 
than their dynamic counterparts: RJump should cost 2, and RJUMPI and RJUMPV 
should cost 4. 


Rationale 
Relative addressing 


We chose relative addressing in order to support code which is relocatable. This also 
means a code snippet can be injected. A technique seen used prior to this EIP to 
achieve the same goal was to inject code like PUSHn PC ADD JUMPI . 


We do not see any significant downside to relative addressing and it allows us to also 
deprecate the pc instruction. 


Immediate size 


The signed 16-bit immediate means that the largest jump distance possible is 32767. 
In the case the bytecode at Pc=@ starts with an RJump , it will be possible to jump as 
far as PC=32770 . 


Given MAX_CODE_SIZE = 24576 (in EIP-170) and MAX_INITCODE_SIZE = 49152 (in EIP- 
3860), we think the 16-bit immediate is large enough. 
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A version with an 8-bit immediate would only allow moving pc backward by 125 or 
forward by 127 bytes. While that seems to be a good enough distance for many for- 
loops, it is likely not good enough for cross-function jumps, and since the 16-bit 
immediate is the same size as what a dynamic jump would take in such cases (3 
bytes: JUMP PUSH1 n ), we think having less instructions is better. 


Should there be a need to have immediate encodings of other size (such as 8-bits, 
24-bits or 32-bits), it would be possible to introduce new opcodes, similarly to how 
multiple PUSH instructions exist. 


PUSHn JUMP Sequences 


If we chose absolute addressing, then rjump could be viewed similar to the sequence 
PUSHn JUMP (and RJUMPI similar to PUSHn JuMPI ). In that case one could argue that 
instead of introducing a new instruction, such sequences should get a discount, 
because EVMs could optimise them. 


We think this is a bad direction to go: 


1. It further complicates the already complex rules of gas calculation. 
2. And it either requires a consensus defined internal representation for EVM 
code, or forces EVM implementations to do optimisations on their own. 


Both of these are risky. Furthermore we think that EVM implementations should be 
free to chose what optimisations they apply, and the savings do not need to be 
passed down at all cost. 


Additionally it requires a potentially significant change to the current 
implementations which depend on a streaming one-by-one execution without a 
lookahead. 


Relation to dynamic jumps 


The goal was not to completely replace the current control flow system of the EVM, 
but to augment it. There are many cases where dynamic jumps are useful, such as 
returning to the caller. 


It is possible to introduce a new mechanism for having a pre-defined table of valid 
jump destinations, and dynamically supplying the index within this table to 
accomplish some form of dynamic jumps. This is very useful for efficiently encoding a 
form of “switch-cases” statements. It could also be used for “return to caller” cases, 
however it is likely inefficient or awkward. 


Lack of JUMPDEST 


JUMPDEST serves two purposes: 
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1. To efficiently partition code — this can be useful for pre-calculating total gas 
usage for a given block (i.e. instructions between JumPpesT s), and for JIT/AOT 
translation. 
2. To explicitly show valid locations (otherwise any non-data location would be 
valid). 


This functionality is not needed for static jumps, as the analysers can easily tell 
destinations from the static jump immediates during jumpdest-analysis. 


There are two benefits here: 


1. Not wasting a byte fora jumppest also means a saving of 200 gas during 
deployment, for each jump destination. 

2. Saving an extra 1 gas per jump during execution, given JumPDEST itself cost 1 
gas and is “executed” during jumping. 


RJUMPV fallback case 


If no match is found (i.e. the default case) in the RJUMPV instruction execution will 
continue without branching. This allows for gaps in the arguments to be filled with 
ə s, and a choice of implementation by the programmer. Alternate options would 

include exceptional aborts in case of no match. 


Backwards Compatibility 


This change poses no risk to backwards compatibility, as it is introduced at the same 
time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code 
which is not EOF formatted). 


Test Cases 
Validation 
Valid cases 


e RJUMP / RJUMPI / RJUMPV With JUMPDEST as target 
o relative_offset is positive/negative/ o 

e RJUMP / RJUMPI / RJUMPV with instruction other than JuMPDEST as target 
o relative_offset is positive/negative/ o 

e RJuMPV with various valid table sizes from 1 to 256 


Invalid cases 


e RJUMP / RJUMPI / RIUMPV with truncated immediate 

e RIUMP / RJUMPI / RIUMPV as a final instruction in code section 

e RJUMP / RJUMPI / RJUMPV target outside of code section bounds 
e RJUMP / RJUMPI / RJUMPV target push data 
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e RJUMP / RJUMPI / RJUMPV target another RJUMP / RJUMPI / RJUMPV immediate 


argument 
Execution 
e RJUMP / RJUMPI / RJUMPV in legacy code aborts execution 
e RJUMP 
o relative_offset is positive/negative/ ə 
e RJUMPI 


o relative_offset is positive/negative/ ə 
=m condition equals © 
= condition does not equal ə 
e RJUMPV @ relative_offset 
o case equals o 
o case does not equal ə 
e RJUMPV with table containing positive, negative, o offsets 
o case equals o 
o case does not equal ə 
o case Outside of table bounds ( case > max_index , fallback case) 
o case > 255 


Reference Implementation 


# The ranges below are as specified in the Yellow Paper. 
# Note: range(s, e) excLudes e, hence the +1 
valid_opcodes = [ 

*range(@x0@, Ox@b + 1), 

*range(@x1@, @x1d + 1), 

0x20, 

*range (0x30, Ox3f 

*range(0x40, 0x48 


+ 1), 
+ 1), 
*range(0x50, @xS5e + 1), 
*range(0x60, Ox6f + 1), 
*range(0x70, Ox7f + 1), 

*range(0x80, Ox8f + 1), 

*range(0x90, @x9f + 1), 

*range(0xað0, Oxa4 + 1), 

# Note: @xfe is considered assigned. 
*range(@xf@, Oxf5 + 1), Oxfa, Oxfd, Oxfe, Oxff 


# STOP, RETURN, REVERT, INVALID, SELFDESTRUCT 
terminating opcodes = [ 0x00, Oxf3, Oxfd, Oxfe, Oxff ] 


immediate_sizes = 256 * [ð] 
2 # RIUMP 
2 # RIUMPI 


immediate_sizes[@x5c] 


immediate_sizes[@x5d] 
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for opcode in range(@x60, @x7f + 1): # PUSH1..PUSH32 
immediate_sizes[opcode] = opcode - @x6@ + 1 


# Raises ValidationException on invalid code 

def validate_code(code: bytes): 
# Note that EOF1 already asserts this with the code section requirements 
assert len(code) > @ 


opcode = @ 
pos = ð 
rjumpdests = set() 


immediates = set() 
while pos < len(code): 
# Ensure the opcode is valid 
opcode = code[pos | 
pos += 1 
if not opcode in valid_opcodes: 
raise ValidationException("undefined instruction") 


pc_post_instruction = pos + immediate _sizes[opcode] 


if opcode == @x5c or opcode == @x5d: 
if pos + 2 > len(code): 
raise ValidationException("truncated relative jump offset") 
offset = int.from_bytes(code[pos:pos+2], byteorder = "big", signed = Trt 


rjumpdest = pc_post_instruction + offset 
if rjumpdest < © or rjumpdest >= len(code): 
raise ValidationException("relative jump destination out of bounds") 


rjumpdests.add(rjumpdest) 
elif opcode == @x5e: 
if pos + 1 > len(code): 
raise ValidationException("truncated jump table") 
jump_table size = code[pos] + 1 


pc_post_instruction = pos + 1 + 2 * jump_table size 
if pc_post_instruction > len(code): 
raise ValidationException("truncated jump table") 


for offset_pos in range(pos + 1, pc_post_instruction, 2): 
offset = int.from_bytes(code[offset_pos:offset_pos+2], byteorder = ' 


rjumpdest = pc_post_instruction + offset 
if rjumpdest < ð or rjumpdest >= len(code): 

raise ValidationException("relative jump destination out of bour 
rjumpdests.add(rjumpdest) 
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# Save immediate value positions 
immediates.update(range(pos, pc_post_instruction) ) 
# Skip immediates 

pos = pc_post_instruction 


# Ensure Last opcode's immediate doesn't go over code end 
if pos != len(code): 
raise ValidationException("truncated immediate") 


# opcode is the *Last opcode* 
if not opcode in terminating opcodes: 
raise ValidationException("no terminating instruction") 


# Ensure relative jump destinations don't target immediates 
if not rjumpdests.isdisjoint(immediates): 
raise ValidationException("relative jump destination targets immediate") 


Security Considerations 
TBA 
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